From: "Dave Butler" <[email-masked]>
Date: Tue, 7 Sep 93 13:35:26 EDT

This append is the result of some discussions held among Roy Dixon, Allen
Carriker, Gene Cox and me (Dave Butler) here at IBM.  We think there are
three problems that should be addressed in this siglet.

1.  looping of SNA test frames and NetBIOS NQ (Name Query),
2.  duplication of UI frames addressed to a group (functional) address
    (i.e. NetBIOS), and
3.  excessive frame copying by transparent bridge.

Let us take these one at a time...

LOOPING OF SNA TEST FRAMES AND NetBIOS NQ (Name Query)

      LAN segment A                          LAN segment B
            |-                                     |-
           -|  +--------+              +--------+  |
            |--| DLSw J |--(TCP cnxn)--| DLSw L |--|
            |  +--------+              +--------+  |-
       [X]--|                                     -|
            |-                                     |--[Y]
           -|                                     -|
            |- +--------+              +--------+  |-
            |--| DLSw K |--(TCP cnxn)--| DLSw M |--|
           -|  +--------+              +--------+  |-
            |                                      |

Suppose that station [X] broadcasts a test frame seeking station [Y].  The
test frame is picked up by both DLSw J and K, and each forwards CANUREACH to
its respective partner DLSw.  DLSw L and M each put a test frame frame on LAN
segment B on behalf of [X], L's test frame is copied by M, and M's is copied by
L. Both DLSw L and M forward CANUREACH to their respective partners, J and K.
DLSw J and K each generate an test frame on LAN segment A, and the loop is
complete.

Note that after one turn around the above loop, the test frames transmitted
by J and K are indistinguishable from one that might be transmitted by [X]
itself as it retries its connection setup.  DLSw will simply drop these frames
in the same way that it would drop a connection-retry test frame from [X].
Recall that retries are not carried on the WAN, but instead are retried on the
"other" side of the WAN.  This is one of the ways DLSw reduces the WAN traffic.
So the loop is not infinite, it is terminated after a single turn, by a
mechanism that is already part of the DLSw definition.

Note also that the above scenario can lead to failure of the session to
start, depending on timing. If the transparent bridges in DLSw L and DLSw M
both learn that station [X] is on LAN segment B, they will not copy the test
response from station [Y].

As our discussions have progressed, we have become more and more convinced
that the spanning tree algorithm is not a solution to this problem, for the
same reasons that others have already expressed:  because the DLSw connection
forwards SNA and NetBIOS only, and participation of DLSw in the spanning tree
may cause some other parallel bridge connection to enter the blocked state.
With the other connection blocked, SNA and NetBIOS could be transported, but
the other protocols would be broken.

We recommend caution in considering solutions that require data to be
carried in the test-frame.  The i-field of test has been used for other
purposes (IBM 3174, for example), so cooperation among the (various?)  users
would be required.

DUPLICATION OF UI FRAMES ADDRESSED TO A GROUP (FUNCTIONAL) ADDRESS

I don't think this topic has been mentioned before in this forum.  The
looping can originate in the same way as for test frames and NetBIOS NQ, but
there is no simple mechanism to detect and stop it.  Since these frames are
multicast to a group address, they must be forwarded by each data link switch,
and if the network configuration has any loops, these frames will never stop
circulating.

On token-ring LANs, there is no loop, because the routing information in the
packet allows forwarders to avoid broadcasting the packet on rings (including
the DLSw virtual ring) where it has already been broadcast.

For either token-ring or Ethernet LANs, whenever there are parallel data
link switches between a pair of LAN segments, each DLSw will copy these frames
to the WAN, resulting in unnecessary duplication of traffic.

IBM's experience is that NetBIOS installations have a significant amount of
traffic of this type.

Any solutions that come out of the SIGlet should address this problem as well
as the looping of test-frames and NetBIOS NQs.

EXCESSIVE FRAME COPYING BY TRANSPARENT BRIDGE

In the 6611 implementation, the transparent-bridge function in the router is
used to attach the DLSw to transparent-bridged LANs.

The bridge learns the locations of stations on each side of the bridge by
watching the frames that pass by (learning), and selectively copying only those
frames for which the destination is on the other side.

When a DLSw transmits a test frame to the transparent-bridged LAN on behalf
of another station, the bridge attaching the DLSw to the LAN learns that the
origin station is reachable through the DLSw.  This learning occurs in the
bridge regardless of whether this DLSw is ultimately selected to carry the
prospective session.  Forever after, the bridge will copy frames destined for
the station from which the test frame came.  They are passed across the channel
to the LLC, which drops the frame since there is no link-station.  This
unnecessary copying of frames contributes to the load on the channel and the
processor.

To illustrate, suppose that in the configuration shown above, the
transparent bridge in router L learns that [X] is on LAN segment A, but the
DLSw connection between [X] and [Y] is established using routers K and M.
Traffic bound from station [Y] to [X] will be copied by the transparent bridge
in router L and must be discarded by the DLSw, even though router L is not
involved in the DLSw connection.